⚠️ No Changeset found

Latest commit: abf58c0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

(...) do we need to differentiate between absent version specifier and Always? (...)
@ggiraldez

The main reason is for the code generation engine, we expect most items of a parsed AST (of a language definition) to always have a span, most of the logic to derive spanned types works that way. So a SpannedVersionSpecifier has a Span, always. An Option<SpannedVersionSpecifier> may not have a span (if it's absent).

As far as I could see we treat Option<...> as special cases sometimes, I think is possible to have similar logic for Default structs (like the new VersionSpecifier) but you'd need to have some way of either differentiating between an explicit Always and an implicit one, or guarantees that no Always will need a span (no error messages).

What this change does allow is that further down the stream, for example when building a lexer, we can simply use .unwrap_or_default().

I agree it'd be a bigger win in ergonomics if we could get rid of the Option entirely, but it needs more work.

I agree it'd be a bigger win in ergonomics if we could get rid of the Option entirely, but it needs more work.

I see. I wasn't considering the model generation layer (partly because I haven't explored that part of the code sufficiently) and was thinking in terms of the model as a result, but they are tightly coupled. Thanks for the explanation!